4. Transport Server Services
Exchange Server 2010 installs various Windows services
so that Exchange can automatically run during startup and does not
depend on administrative interaction. In most situations you do not
need to consider their purpose because they are configured
automatically during Exchange 2010 setup. However, once you face issues
or a service does not start automatically during Exchange startup, it
is good to know the purpose of the service and whether there are any
implications when the service is not started.
4.1. Hub Transport Services
Table 4 shows the services that are added to the operating system when adding the Exchange Server Hub Transport role to a server.
Table 4. Exchange Services for Hub Transport Role
| SERVICE | DESCRIPTION | BEST PRACTICE INFORMATION |
|---|
| Microsoft Exchange Active Directory Topology | This
service reads information from all Active Directory partitions. The
data is cached and then used by Exchange 2010 servers to discover the
Active Directory site location of all Exchange services in the
organization. It is also responsible for updating the site attribute of
the Exchange server object in Active Directory. | Runs
on all Exchange servers but Edge servers. Stopping this service is the
quickest way to stop all Exchange services because all other Transport
related services will also be stopped. |
| Microsoft Exchange Anti-spam Update | This
service manages the anti-spam automatic updates for Exchange. It
installs the Microsoft standard set of anti-spam signature files
received by Windows Update. | You can stop this service and change it to service startup manual on Hub Transport
servers that do not have or need the Microsoft anti-spam feature
enabled. You don't need this service if you use Microsoft Forefront
Protection for Exchange 2010 because it will install its own premium
update service. |
| Microsoft Exchange EdgeSync | This service is responsible for the EdgeSync feature to synchronize the directory information with an Edge AD LDS. | This service needs to run on any hub transport server that participates in an Edge Synchronization. |
| Microsoft Exchange Monitoring | This service allows applications to call the Exchange diagnostic cmdlets. | This
service should be started when you consider implementing monitoring
tools such as System Center Operations Manager. Otherwise you don't
need to start it. |
| Microsoft Exchange Service Host | This
service is the replacement for the System Attendant service found in
previous Exchange version and is responsible, for example, for
calculating MailTips. | The service should always be in a running state; otherwise, the Test-ServiceHealth cmdlet will recognize it and report a fail. |
| Microsoft Exchange Protected Service Host | Provides a host for several Microsoft Exchange services that must be protected from other services. | This service is started automatically and is used by Exchange for internal processing. |
| Microsoft Exchange Transport | This is the core transport service and is responsible for routing messages between servers. | This service is required for every Hub or Edge Transport server. |
| Microsoft Exchange Transport Log Search | Provides remote search capability for Microsoft Exchange Transport log files. | This
service should be started if you want to use the Tracking Log Explorer
or provide Delivery Reports to your users. The CAS servers will access
it to retrieve tracking information. |
4.2. Edge Transport Services
The Edge Transport services are installed to the Windows OS during Exchange setup. Table 5 lists Edge Transport–specific services (that differ from Hub Transport services) along with their purpose and best practice information.
Table 5. Exchange Services for Edge Transport Role
| SERVICE | DESCRIPTION | BEST PRACTICE INFORMATION |
|---|
| Microsoft Exchange ADAM | Stores configuration data and recipient data in AD LDS database on the Edge Transport server. | All other Exchange services depend on this service, so stopping this service is the quickest way to stop all services. |
| Microsoft Exchange Credential Service | Monitors
credential changes that occur in the Exchange organization and are
replicated to AD LDS and installs these changes on the Edge Transport
server. | This service is required for every Edge Transport server. |
5. Delivery Status Notifications
Delivery
status notifications (DSNs) notify the Microsoft Exchange Server 2010
administrator or e-mail sender of the status of a particular message.
DSN messages are a
critical part of troubleshooting e-mail connectivity issues between
local Exchange recipients and issues between your Exchange organization
and the remote e-mail servers on the Internet.
DSN messages occur with the following error code areas:
4.x.x This indicates a temporary problem where for example a mailbox server was unavailable and typically resolve themselves.
5.x.x
This status code indicates a permanent problem and results in a
Non-delivery Report (NDR) being sent to the originator of the message.
For messaging administrators the 5.x.x DSN status codes are the more interesting ones for troubleshooting for example. Table 6 provides a description of important DSN status codes.
Table 6. Overview of 5.x.x DSN Status Codes
| DSN STATUS CODE | DESCRIPTION |
|---|
| 5.1.1 | Bad destination mailbox address. E-mail address or domain does not exist. |
| 5.1.4 | Destination mailbox address ambiguous. Two or more recipients in the Exchange organization have the same address. |
| 5.2.2 | Mailbox full. The recipient's mailbox has exceeded its storage quota and is no longer able to accept new messages. |
| 5.3.4 | Message too big for system. The message exceeds the size limit configured. |
| 5.4.6 | Routing loop detected. A configuration error has caused an e-mail loop. |
| 5.5.3 | Too many recipients. The total of recipients of the message exceeds the total number of recipients allowed in a single message. |
| 5.7.1 | Delivery not authorized. The sender of the message is not allowed to send messages to the recipient. |
| 5.7.2 | Unable
to relay. The sending e-mail system is not allowed to send messages to
an e-mail system where that e-mail system is not the final destination
of the message. |
| 5.7.3 | Client was not authenticated. The sending e-mail system did not authenticate. |
DSN messages and DSN codes
are commonly configured either to modify the DSN message or to
configure what DSN codes are copied to the Postmaster mailbox.
5.1. Modifying DSN Messages
Exchange 2010 is extremely customizable with regard to system messages and allows you to modify any DSN message using the New-SystemMessage
cmdlet. You can define the DSN message, the language that is used, and
whether the message is available internally only. For example, to
configure a custom text message for the DSN code 5.1.1 use the
following cmdlet:
New-SystemMessage -DSNCode 5.1.1 -Text "E-Mail Address does not exist" -Internal $false
-Language En
Customizing your DSN
message is quite a timely effort. However, when your company's policy
requires displaying custom system messages—for example, to provide user
guidance—you can use this feature.
5.2. Creating DSN Message Copies
By default Exchange does not
keep a copy of DSN messages but instead discards them automatically to
preserve space. In some situations you will want to receive a DSN
message to understand your messaging system. For example, when you're
migrating from a different e-mail system and you just created all
mailboxes with their respective original e-mail addresses, you may want
to verify which e-mail addresses are not yet available in the system.
Therefore, you'd want to determine which e-mail addresses are currently
rejected.
If you want to keep DSN messages, you first need to configure the Exchange Recipient Reply Recipient (also known as Postmaster mailbox) using the following cmdlet:
Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient <PostmasterMailbox>
Then you need to specify the DSN status codes for which you want Exchange to send DSNs to the Postmaster mailbox. This is done using a cmdlet such as the following:
Set-TransportConfig -GenerateCopyOfDSNFor 5.1.1
Note: In
an Exchange organization with EdgeSync, all these settings are
configured on a Hub Transport server in your Exchange organization, not
on the Edge Transport servers. If you run Edge Transport servers
without EdgeSync, you need to configure the Set-TransportConfig –ExternalPostmasterAddress <E-Mail Address> cmdlet as well.
6. Message Latency Measurement
New to Exchange 2010 is the ability to measure service levels for messages that flow through the system. Latency measurements are implemented into the core transport service and logged in Message Tracking.
Exchange 2010 comes with the ConvertTo-MessageLatency.ps1 script (found in the <Exchange_Install_Path>\Scripts folder) that extracts server and end-to-end latency information from the tracking
log. It can be used to convert the data structure of a tracking log
event to present a more friendly presentation of the component latency
data. Thus you can use the script to identify messages why they've
taken a long time to deliver to the users and what Hub Transport
servers caused the delay. An example is found in Figure 3.
Additionally, the
tracking logs are processed automatically and are summarized in log
files located in the following directories found under <Exchange_Installation_Path>\ TransportRoles\Logs on each transport server:
The logs are in CSV format and are automatically produced to provide statistics for a single server. You can thus use Microsoft Excel to look at the log files.
If you use System Center Operations Manager (SCOM),
including the Exchange Management Pack (MP), the log files are
aggregated to the System Center data warehouse database. This is where
the reports
are generated. These reports show hourly and daily server statistics as
well as active users and distribution group usage.
7. Shadow Redundancy
Exchange Server 2010 introduces the shadow redundancy feature, which provides redundancy for messages
for the entire time they are in transit. Copies of messages that are
submitted to a Hub Transport server are stored in the transport queue
until the next hop reports successful delivery of the message. If the
next hop doesn't report successful delivery and it fails, the message
is resubmitted for delivery. Shadow Redundancy is actually made of three shadowing techniques:
Shadow Queue Stores messages not yet confirmed by the next hop to be delivered.
Delayed Acknowledgment (Transport Wormhole) The connections are held open until the delivery is confirmed on the next hop.
System Generated Reference Count Includes a pattern to ensure that system-generated messages are also copied to the shadow queue.
The Shadow Redundancy Manager (SRM) is the core component of a Transport server that is responsible for managing shadow
redundancy. The SRM is responsible for maintaining the following
information for all the primary messages that a server is currently
processing:
The SRM is responsible for the following actions for all the shadow messages that a server has in its shadow queues:
Maintaining the list and checking primary server availability for each shadow message
Processing discard notifications from primary servers
Removing shadow messages from the database once it receives all expected discard notifications
Deciding when the shadow server should take ownership of shadow messages, thus making it the primary server
Figure 4 shows how shadow
redundancy keeps a copy of the messages that have not yet been
delivered by the Hub Transport server located in the Active Directory
site Site-Fresno. As soon as the Hub Transport in Fresno is able to
send the message to the next hub, the Hub Transport located on
Berlin-Ex01 receives an acknowledgment and will remove the messages
from the shadow redundancy queue.
8. Message Throttling
Message throttling is a new feature of Exchange 2010 that implements limits on Hub Transport or Edge Transport servers to prevent accidental or intentional inundation of system
resources. These limits are defined on areas such as the number of
messages or connections that are processed by the Transport server.
Message
throttling involves limits on message processing rates, SMTP connection
rates, and SMTP session timeout values. These limits protect the
Transport servers from being overwhelmed by accepting and delivering too many messages or connections.
Message throttling is enabled by default but you can adapt message throttling options on the Transport server, the Send connector and Receive connector. Options that you can define include the MaxConcurrentMailboxDeliveries parameter on Transport servers and the MaxInboundConnection and MaxProtocolErrors parameters on Receive connectors.
Exchange 2010 Service
Pack 1 adds Delivery Class Throttling to the feature set. This adds the
ability to classify a message based on certain characteristics and
assign it a delivery class. Throttling will investigate messages when
they are sent by individual users and add a cost to each message based
on message size, number of recipients, and frequency. This cost factor
allows assigning a delivery class to the messages.
The behavior is similar to
postal mail. First-class mail gets delivered faster than regular
postage mail. The higher the delivery class, the higher the message
priority is in the connector queue. For example, Delivery Class
Throttling will prioritize small messages with just a couple of
recipients over large bulk messages with many recipients in the message
queue.
For more information about message throttling, including all available message throttling options, see http://technet.microsoft.com/en-us/library/bb232205.aspx.
9. Back Pressure
Back pressure is a system-resource monitoring feature of the Microsoft Exchange Transport service available on the Hub Transport or Edge Transport server role.
Back pressure monitors important system
resources, such as available hard-disk drive space and available
memory. If utilization of a system resource exceeds the specified
limit, the Exchange server stops accepting new connections and
messages. This prevents system resources from being completely
overwhelmed, and enables the Exchange server to deliver
the messages queued to be sent. When utilization of the system resource
returns to a normal level, the Exchange server accepts new connections
and messages.
For each monitored system
resource on a Hub Transport server or Edge Transport server, the
following three levels of resource utilization are applied:
Normal The resource is not overused. The server accepts new connections and messages.
Medium The resource is slightly overused. Back
pressure is applied to the server in a limited manner. Mail from
senders in the authoritative domain can flow. However, the server
rejects new connections and messages from other sources.
High The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new connections and messages.
Note: Because Microsoft does not recommend modifying any back pressure settings, parameters were not included in this section, but you can access them at http://technet.microsoft.com/en-us/library/bb201658.aspx. You configure back pressure settings in the EdgeTransport.exe.config file located at <Exchange_Server_Install>\Bin.
